Microservices vs SOA: What’s the Difference?
Understanding the best way to develop and deploy applications is an important consideration for any data-driven organization today. Options such as service oriented architecture (SOA) and microservices offer valuable flexibility for building and running applications that traditional monolithic approaches don’t. However, it can be difficult to understand the differences between the two in order to identify which is best for your business.
Microservices structure an application as a series of distinct, single-purpose services while SOA is a group of modular services that “talk” together to support applications and their deployment. These two approaches have critical differences in architecture, component sharing, data governance, communication and other elements that determine which situation each method is best used for, and how it impacts the overall business.
What is service-oriented architecture?
Service-oriented architecture was largely created as a response to traditional, monolithic approaches to building applications. SOA breaks up the components required for applications into separate service modules that communicate with one another to meet specific business objectives. Each module is considerably smaller than a monolithic application, and can be deployed to serve different purposes in an enterprise. Additionally, SOA is delivered via the cloud and can include services for infrastructure, platforms, and applications.
SOA’s two main roles are as a service provider and a service consumer. Its service provider layer includes the different services involved in SOA, while the consumer layer operates as the user interface.
SOA delivers four different types of services:
- Functional services are used for business operations
- Enterprise services implement the functionality
- Application services are specific for developing and deploying apps
- Infrastructure services are for non-functional processes such as security and authentication
Traditionally, SOA involves an enterprise service bus (ESB) as a means of coordinating and controlling these services.
What is a microservice?
Microservice architecture is generally considered an evolution of SOA as its services are more fine-grained, and function independently of each other. Therefore, if one of the services fail within an application, the app will continue to function since each service has a distinct purpose. The services in microservices communicate via application programming interfaces (APIs) and are organized around a particular business domain. Together, these services combine to make up complex applications.
Since each service is independent, a microservice architecture can scale better than other approaches used for application building and deployment. This characteristic also gives microservice applications more fault tolerance than other application development methods. Microservices are frequently built and deployed in the cloud; in many instances they operate in containers.
Microservices vs SOA: Identifying the differences
Many of the chief characteristics of SOA and microservices are similar. Both involve a cloud or hybrid cloud environment for developing and running applications, are designed to combine multiple services necessary for creating and using applications, and each effectively breaks up large, complicated applications into smaller pieces that are more flexible to arrange and deploy. Because both microservices and SOA function in cloud settings, each can scale to meet the modern demands of big data size and speeds.
Nevertheless, there are many differences between SOA and microservices that determine the use case each is suitable for:
| Microservices | SOA | |
|---|---|---|
| Architecture | Designed to host services which can function independently | Designed to share resources across services |
| Component sharing | Typically does not involve component sharing | Frequently involves component sharing |
| Granularity | Fine-grained services | Larger, more modular services |
| Data storage | Each service can have an independent data storage | Involves sharing data storage between services |
| Governance | Requires collaboration between teams | Common governance protocols across teams |
| Size and scope | Better for smaller and web-based applications | Better for large scale integrations |
| Communication | Communicates through an API layer | Communicates through an ESB |
| Coupling and cohesion | Relies on bounded context for coupling | Relies on sharing resources |
| Remote services | Uses REST and JMS | Uses protocols like SOAP and AMQP |
| Deployment | Quick and easy deployment | Less flexibility in deployment |
Architecture
Microservices architecture is based on smaller, fine-grained services that are focused on a single purpose and can function independently of one another — but interact to support the same application. Consequently, microservices is architected to share as few service resources as possible. Since SOA has larger, more modular services that are not independent of one another, it’s architected to share resources as much as possible.
Component sharing
The independence of microservices minimizes the need to share components and makes the services more resistant to failure. Additionally, the relative lack of component sharing enables developers to easily deploy newer versions, and scale individual services much faster than with SOA.
On the other hand, component sharing is much more common in SOA. In particular, services share access to an ESB. Thus, if there are issues with one service in relation to the ESB, it can compromise the effectiveness of the other connected services
Granularity
A SOA’s services are large, with some of the modular services resembling monolithic applications. Due to each service’s capability to scale, SOAs typically have a wider range of focus.
The more granular nature of microservices means that individual services excel in performing a single specific task. Combining those tasks results in a single application.
Data storage
With microservices, the individual services generally have their own data storage. With SOA, almost all of the services share the same data storage units.
Sharing the same data storage enables SOA services to reuse shared data. This capability is useful for maximizing data’s value by deploying the same data or applications between business units. However, this capability also results in tight coupling and an interdependence between services.
Governance
Because SOA is based on the notion of sharing resources, it employs common data governance mechanisms and standards across all services.
The independence of the services in microservices does not enable uniform data governance mechanisms. Governance is much more relaxed with this approach, as individuals deploying microservices have the freedom to choose what governance measures each service follows — resulting in greater collaboration between teams.
Size and scope
Size and scope is one of the more pronounced differences between microservices and SOA. The fine-grained nature of microservices significantly reduces the size and scope of projects for which it’s deployed. Its relatively smaller scope of services is well-suited for developers. In contrast, the larger size and scope of SOA is better for more complicated integrations of diverse services. SOA can connect services for cross-enterprise collaboration and other large integration efforts.
Communication
SOA communication is traditionally handled by an ESB, which provides the medium by which services “talk” to each other. However, using an ESB can slow the communication of services in SOA. Microservices relies on simpler messaging systems, like APIs which are language agnostic and enable quicker communication.
Coupling and cohesion
While SOA is based on sharing components, microservices is based on the concept of ‘bounded context’. Bounded context is the coupling of a component and its data without many other dependencies — decreasing the need to share components. The coupling in microservices can also involve its operating system and messaging, all of which is usually included in a container.
This type of coupling results in high cohesion, so that any points of failure in a particular service are quickly isolated and addressed before compromising application performance. In contrast, SOA’s focus on sharing makes its systems slower and more prone to failure.
Remote services
SOA and microservices use different protocols for accessing remote services. The main remote access protocols for SOA include Simple Object Access Protocol (SOAP) and messaging like Advanced Messaging Queuing Protocol (AMQP) and Microsoft Messaging Queuing (MSMQ).
The most common protocols for microservices are Representational State Transfers (REST) and simple messaging such as Java Messaging Service (JMS). REST protocols are frequently used with APIs. The protocols for microservices are more homogenous than those for SOA, which are typically used for heterogeneous interoperability.
Deployment
Ease of deployment is another major difference between microservices and SOA. Since the services in microservices are smaller and largely independent of one another, they are deployed much more quickly and easily than those in SOA. These factors also make the services in microservices easier to build.
SOA deployments are complicated by the fact that adding a service involves recreating and redeploying the whole application, since services are coupled together.
Microservices vs SOA: Which is better for your business?
There are several points to consider when deciding whether microservices or SOA is better for a particular business. SOA is a modular means of breaking up monolithic applications into smaller components, while microservices provides a smaller, more fine-grained approach to accomplishing the same objective. Both of these architectures are routinely run in the cloud, which increases the flexibility for building and deploying applications. Ultimately, the best approach depends on each business’s own unique needs and use case.
However, the reality is that both SOA and microservices are applicable in different use cases for the same organization. Talend Data Fabric enables organizations to quickly access both microservices and SOA through cloud or hybrid cloud deployments. As a comprehensive suite of apps, Talend Data Fabric provides the means for managing data resources in the cloud and ensuring secure data integration. Try Talend Data Fabric today to master application building and deployment.
